昨天受邀參加 CNTUG 社群所舉行的一場線上分享會，來跟大家探討一下最近 Kubernetes 1.20 的議題，也就是 dockershim 的退休倒數計畫
為了能夠更加充分地去理解這次的改動，我們必須要對 Docker, Kubernetes, CRI 以及 OCI 這四個關鍵字有所瞭解，當你對這些東西的彼此關係都熟悉與清楚後，你就會發現這次的改動其實沒太大影響，對於開發者來說幾乎是毫無感覺。而系統維運者甚至服務提供者則是會因為底層軟體的變動而會有一些轉移的過程需要去思索該怎麼做。
昨天與會人數將近125人，討論非常踴躍，等會議錄影處理完畢後會再釋出，到時候大家可以再次回味。
這邊用比較簡單的敘述去幫大家稍微釐清一下標題四個元件的差異。
以下概念我們主要探討的是 2020 當下的架構，過往舊版的架構不列入考慮之中，有心力與興趣的可以再去挖掘這些架構演進
1. Docker 是 Contianer 的解決方案之一，除了 Docker 外也有別的方案可以提供 Container 的應用與環境，因此要注意，不要再說 Container 就是 Docker。 這句話於現在是一個完全錯誤的說法
2. 有一個叫做 OCI (Open Container Initiative) 的概念，旨於標準化 Container 環境，該標準定義了兩大項，分別是 Runtime 以及 Image.
Runtime 定義了該如何運行一個 Container，而 Image 則定義了 Image 的格式
4. Docker 解決方案產生出的 image 是完全遵循 OCI Image 格式，而 Docker 運行的 Container 也是遵循 OCI Runtime。
精準的說 Docker 指令會把內容送給 Dockerd，而 dockerd 會再把運行的指令送給 containerd，而 containerd 最後會叫起一個基於 OCI Runtime 標準實作的解決方案 Runc，最後產生出運行的 Container。
4. 根據上述架構，Docker 產生出的 image 以及運行的 container 其實最後都跟 OCI 標準脫不了勾
5. Kubernetes 一開始就表明我是 Container 管理平台，不是 Docker 管理平台，希望能夠支援不同的 Container 解決方案。 Docker 只是其中之一罷了
6. Kubernetes 希望透過 CRI (Container Runtime Interface) 來銜接各式各樣的容器解決方案
7. Docker 出世的時間早於 Kubernetes，因此 Kubernetes 無法使用 CRI 來直接銜接 Docker
8. 因此 Kubernetes 設計與實作了一個名為 dockershim 的中間層，該層透過 CRI 與 Kubernetes 溝通，同時往下與 docker 溝通來創建最後的 container.
9. 一旦 dockershim 被移除後， kubernetes 還是繼續使用 CRI 的介面與 Container 解決方案溝通，只是 docker 這邊就找不到一個很好的角色來串接彼此的對話。
10. 其他的解決方案，譬如 containerd, CRI-O，其底層的實作也都相容於 OCI 標準。這意味你透過 docker build 產生的 image 是可以於上述兩個解決方案去運行的。
因為大家都是基於 OCI 標準
所以這次的影響對於開發者來說毫無感覺，繼續使用 docker 還是可以讓你的服務交給 Kubernetes 處理，只要底層使用的解決方案也是相容 OCI 標準。
相關影片: https://www.youtube.com/watch?v=nc3mBN3LzvM&feature=youtu.be
相關投影片: https://www2.slideshare.net/hongweiqiu/the-relationship-between-docker-kubernetes-and-cri
Search